双重校验锁：Java并发编程中的陷阱

最近学习java并发编程，发现一个之前踩过很多次而没有发觉的java并发编程陷阱

先看如下代码：

public static Singleton getInstance(){
	if(instance == null){
		synchronized(Singleton.class){
			if(instance==null)
				instance = new Singleton();
		}
	}
	return instance;
}

(吐槽一下CSDN的代码编辑功能真不好用）

这个代码是一个Singleton的getInstance（）方法，调用这个方法时，如果Singleton有实例，则返回实例，如果没有实例，调用构造函数（应为private的构造函数）new一个实例出来。这部分代码实现了在并发环境下的单例模式的功能。

这部分代码首先判断instance是否为null，如果确实为null，则进入一个synchronize包围的代码块，相当于上了锁，进入了临界区，为了防止在判断为null到进入临界区的过程中，有线程对其new了一个实例出来，再上锁完成之后，在对instance是否为null进行一次判断，如果这次还是为null，则可以确认确实instance为null，并且此时也不会有其他线程尝试new一个instance出来，因此可以放心地执行new对象的工作。

这个代码在单线程的环境下是没错的（废话），但是如果在并发的环境下，会出现严重的问题。

问题其实出在java的